There exist many legacy server applications that have provided and continue to provide valuable information processing servers to organizations worldwide. Many of these legacy server applications, which are the result of many years of development, contain, store or access many years (and sometimes decades) worth of data. These legacy applications are now being forced to become part of distributed applications (that is, applications which use the services and facilities of many servers and clients). For example, in a typical electronic transaction being performed on a client system (e.g., a personal computer, personal digital assistant, etc.) an individual may, unknowingly, initiate a transaction that involves: an application server (which typically provides the data or business logic processing necessary to deliver up-to-date information; additionally and typically an application server sits along with or between the user and the databases and legacy applications and provides the middleware glue to enable a browser-based application to link to multiple sources of information; with Java-based application servers the processing is performed by Java servlets, JavaServer Page and Enterprise JavaBeans) and other back end systems such as databases or legacy applications.
Many legacy systems deliver to clients a text-based screen which provides a client/user with information and allows a user to input data, modify data or submit a transaction for processing. For example, legacy applications deliver data which was originally designed to be displayed by an IBM 3270 terminal. In the example of the 3270 applications, a screen includes fields where data can be presented to a user or data entered into the field by the user. For example, a screen may contain two fields, one which is a prompt with the text “Name:”, and the second field which contains a person's name or allows a person's name to be entered by a user. Each field besides containing text has attributes, which indicate the text color, background color (which may be associated with many color related attributes such as the color of text, the background color of text, etc.), whether the field is protected, whether the text has been modified, etc.
Two exemplary legacy applications that communicate with client systems are Customer Information Control System (CICS) 3270 applications (where CICS provides terminal routing, password security, transaction logging for error recovery and activity journals for performance analysis amongst other features) and Host 3270 applications.
Present client systems often employ a 3270 terminal emulation product (and the protocols) to render the data transmitted by the legacy application. The terminal emulation product allows a user to view 3270 screens on a personal computer, instead of using a 3270 terminal.
Alternatively, for these two exemplary legacy applications, a Java™ 2, Enterprise Edition (J2EE) Connector Architecture resource adapter (also sometimes referred to as a connector) can be hosted by an application server. The Host on Demand (HOD) and CICS Transaction Gateway products from IBM provide such resource adapters. These resource adapters receive a data stream from a legacy 3270 application and they each provide a product specific programming interface that allows an application to work with the fields of a screen. With today's more powerful graphical user interfaces, the application can display the data in a more meaningful way, such as combining the contents of several screens into a single Web Browser page.
The 3270 data stream is a highly optimized stream which describes a screen image. A resource adapter is at liberty to deliver the screen information in any format it desires. Current resource adapters (CICS and HOD, for example) send a stream which represent each byte on a X by Y screen, modifying invisible screen bytes with extra information about the bytes that make up a field (i.e., foreground color, background color). This mechanism is highly inefficient, compared to a 3270 data stream, when providing full information about a screen image since it requires sending multiple X by Y streams with changes to the invisible bytes to obtain all the possible attribute information.
These resource adapters have other significant shortcomings. For example, these resource adapters currently require the data for the entire screen to be sent, where it could be optimized to only send the data of modified fields. Additionally, when developing applications to interact with the data stream provided by a resource adapter, prior knowledge of-the screen image is necessary so that use of the fields and their location on the screen can be made. Unfortunately, having this prior knowledge of the screen image is not always available.
Further, specific tooling must be created to develop applications that use the facilities offered by a connector or resource adapter. As such, given the examples above, different tooling would have to be created for each of the J2EE resource adapters described above. This is inefficient.
Accordingly, providing an interface that resource adapters can implement to overcome, at least in part, some or all of the shortcomings described above would be desirable.